Many computer systems utilize virtualized memory for security, stability and/or other purposes. In various virtualized-memory systems, a virtual machine monitor (“VMM”) may control direct use of memory and/or computer processors in a computer system. The virtual machine monitor, which may be implemented in software and/or hardware, may allow guest software to run only in virtual machines, each containing their own guest address space defined by virtualized memory addresses.
In various systems, these virtualized memory addresses are mapped to physical memory addresses through the use of page tables controlled by the virtual machine monitor. In some systems, these page tables may specify access permissions for memory pages (hereinafter, may simply referred to as “page”). Thus, a page table may define, for each page of virtualized memory presented to a piece of guest software, whether the guest software may 1) execute instructions from that locations in that page, 2) read from locations in that page, and/or 3) write to locations in that page. In various systems, multiple page tables may be used, or switched to during execution, in order to allow particular accesses, as determined by the VMM.
As an example, pages W and X may hold trusted data, while pages Y and Z may hold trusted code sections. To enable code in pages Y and Z to access data in pages W and X, but prevent code in other pages from accessing data in pages W and X, a page table may provide execute permission for pages Y and Z, and read/write permission for pages W and X.
However, in some scenarios, current page table utilization may introduce problems. For example, in a scenario where code in page Y of the above example were supposed to be allowed to access both pages W and X but code in page Z were only allowed to access page W, then the above described page table would be insufficient to provide proper security, and other page tables would be required. Thus, in some systems, many different page tables must be maintained in order to provide different sets of access permissions for different guest software, increasing resource usage and complexity.
Secondly, in some scenarios, no page table may be sufficient to properly control memory location access permissions, as permissions need to be given at a granularity lower than that of a page. For example, a page Q may hold both trusted data D1 and untrusted data D2. To enable untrusted code to access untrusted data D2, a page table would have to have read/write permission for page Q and execute permission for untrusted code at the same time. This would allow untrusted code to access data D2 so that it can access trusted data D1.
Some systems address these issues by keeping a smaller number of page tables and by modifying them on a per-access basis before use. Thus, for example, if access to an address is needed that is not permitted by a currently-used page table, the VMM (after determination that the access is proper) may modify the current page table to temporarily provide the requested read/write permission. Control may then be transferred back to the guest software for data access execution. After execution of the data access, the control may be transferred back to VMM to restore the original permission.
This process may introduce its own inefficiencies, however. In some systems, more than one computer processor may utilize a given page table. Thus, when a page table needs to be modified temporarily for a data access by one processor, any other processor using the modified page table must be paused or otherwise made to wait so that it does not run using the modified permissions. This processor pausing may slow down performance. Additionally, the page table modification time itself incurs a performance penalty and can be a system stability issue.